[Previous] [Next] [Index] [Thread]

Re: Comments on the new SHTTP draft of July, 1995

> Thanks for your comments, Marc. My responses follow.

Thanks for your responses.

I've re-added the mailing list to the distribution; I hope you don't mind.
I think discussion of refining the specification has to be done in public
if we're to have any chance of reaching consensus in the group (assuming,
hypothetically, that people other than you and me care about this. :-)

> >  As with HTTP in general, the request-line should be considered
> >  case-sensitive; however, for compatibility with earlier versions of
> >  this specification, it is recommended that implementations accept
> >  all case variations.  The asterisk shown here [ ... ]
> As I think I've expressed to you before, I think that this is
> a real mistake in HTTP, so I'm not inclined to extend that
> mistake. 

I'm not particularly fond of case-sensitivity in HTTP in this context either,
but that isn't the point.  It's hard to define new functionality if we're
forever dinking with inconsequential basics.

> >  For 'Content-Privacy-Domain: pkcs-7' acceptable values for this
> >  field are 'base64' and 'binary'.  For compatibility with older
> >  versions of this standard, the value '8bit' should be accepted as
> >  identical to 'binary' but is deprecated.
> 
> Actually, I've been thinking about this, and I meant to write this
> this way: As I remember, the difference between 8-bit and binary
> is line-length, and there are certainly circumstances
> (i.e. a PKCS7 data encoding of a text message) where the line
> lengths will tend to be appropriately short.

Indeed there are, although such things won't be very common (there's no
reason to PKCS7 encode a plain text message.)  However, I still think
the default value should be "binary" and not "8bit".

> >I'm assuming the standard padding mechanism defined in section 6.2 of
> >PKCS-5 (and also in RFC 1423) is used (being generalized for
> >algorithms with block sizes larger than 8 bytes.) I think it's obvious
> >that this is what most people would do in an implementation, but it
> >probably should be explicit since it isn't defined elsewhere as it is
> >for the contents.
> Actually, this doesn't work properly. Consider the case of DES
> where the keylength is exactly equal to the blocksize.

Then you pad by adding eight bytes of value 08.  It's unfortunate that
this adds a whole extra block, but there isn't much by way of a good
alternative, and the use of this padding is pretty darn established.
(Well, there's the alternative of only allowing stream ciphers as
symmetric-head-algorithms, but I hardly think we could do that.)

> >If my understanding and memory are correct, we can't ignore this,
> >because some symmetric-content-algorithms (like RC4) have a variable
> >key length and don't contain information on the effective key length
> >in the  ContentEncryptionAlgorithmIdentifier.  Even without this, you
> >need to be able to tell the precise length of the covered key in order
> >to do MACs with a key-spec of "dek".
> Hmmm... This I'll have to think about more carefully. You're
> right, it's insufficiently clear.  I'm a bit nervous about RC4
> support anyway, but it would be good to be general.

Even without RC4 support, using the dek as a shared secret for a keyed 
hash in the MAC-Info: header requires knowing where the key stops and the pad
begins, and there's no algorithm identifier to provide this information.

> >The "---BEGIN [...] ---" and "---END [...] ---" lines aren't really
> >needed; I'd suggest dictating that implementations should not complain
> >if they're absent.  Both HTTP and the BER structure of a PKCS-7
> >message make it clear where the beginning and end is; more labeling
> >isn't needed.
> Right. I know we've talked about this before and I remember that
> we disagree. I don't expect to convince you of my reasoning,
> though. 

Well, in practice there isn't really any reason to use base64 at all, since
it just eats bandwidth and slows things down.  Since few if any implementations
will actually use this, I'm not enough of a purist to demand it be removed;
just seems a bit silly.

> >So, is the Content-Length: header mandatory on SHTTP/1.1 requests or
> >not?
> No.

Sounds good; probably should get mentioned explicitly (presuming all privacy-
domains that are and ever shall be will have some internal structure that
allows one to recognize the end.  I think this is a safe assumption.)

> It's not meant to be read that way. That is, it's permissible
> to simply say 'RC2-CBC'. Having no parameters is part of
> the syntax of 4.3. 

OK; makes sense (I had been taking that sentence as saying something different,
when it's just a clairification.)

> > [ example deleted ]
> >Are they equivalient, or different?  I believe it is possible to read
> >the current spec either way.
> 
> I intended them to be equivalent. I think that the spec says this.
> However, I can see how this might be seen as unclear.

This sounds reasonable (though I like my interpretation better, since it
could allow for shorter headers in many cases. :-)  Something a tad more
explicit, though, would be nice.  Maybe something like:

  The default values follow.  For all headers except 
SHTTP-Privacy-Enhancements,
  the presence of an optional or required field for a given mode overrides
  the default field for that mode.  With privacy-enhancements, the three
  possible enhancements are orthogonal options.

Hmmm... still a little confusing.  Will think on it.  For the next version,
I'd rather get rid of this "required" and "optional" and "refused" stuff
and just enumerate a list of possibilities, with "none" being one of the
possibilities.  Currently "none" falls into the list but it's hard to rank
it as a preference; it would be nice to have a way to indicate "I prefer
unencrypted messages, but will accept messages encrypted with DES if you
must" and distinguish that from "I prefer DES-encrypted messages, but will
accept unencrypted ones."

> >The two sentences:
> >
> >  'reply' indicates that it is useful for a reply to this message (or
> >  the duration of the connection, for future versions of HTTP that
> >  support retained connections.)
> >
> >and
> >
> >  The 'reply' lifetime indicates the key is good for at least one (but
> >  perhaps only one) dereference of this anchor.
> >
> >seem to contradict each other.  I suggest the latter be retained and
> >the former nixed.  The meaning of "this anchor" in this context is,
> >however, kind of unclear; what anchor?
> The anchor to which the cryptopts block applies.

If it's in a cryptopts block, yes.

> What do you think contradicts? The language about 'retained
> connections'?

Yes.  Being good for perhaps only one transaction, and being good for lots
of transactions over the duration of a connection, are different things.
I'd expect we'll want a different label for "session" keys with longer
lifetimes than a single use.  I'm also still vague on the purpose of "this".

> >I'm inclined to say we just ignore the parity bits, right or wrong, so
> >that the same keys can be used for all various ciphers.  This is
> >probably what existing implementations do, but should be explicitly
> >spelled out somewhere.
> That's what I do.I agree it should be spelled out.

Sounds good.

> >Section 7.3 keeps the rather unpleasant convention of base64 encoding
> >an RFC1485ized DN.  If we want to keep this the way it is for the
> >current version of the protocol I guess I can understand that, but
> >certainly we'll want to do something better in the long run, like
> >base64 encoding the DER of the DN.
> Yeah, I agree this is problematic. It was simply inconvenient
> to change for this version.

These things can wait for the version that's integrated with HTTP-NG.
:-) * 0.5 

- Marc
References: